Skip to content

Backport OCL to 4.18 #96116

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: enterprise-4.18
Choose a base branch
from

Conversation

mburke5678
Copy link
Contributor

@mburke5678 mburke5678 commented Jul 15, 2025

https://issues.redhat.com/browse/OSDOCS-15319

Link to docs preview:
RHCOS image layering -- Added links to additional referencesjust before Modifying a custom layered image, added the Rebuilding and Removing modules.
Modifying a custom layered image -- Updated text
Rebuilding an on-cluster custom layered image -- Module is new to 4.18. Copied from main and 4.19+. NO NEED TO REVIEW text.
Removing an on-cluster custom layered image -- Module is new to 4.18. Copied from main and 4.19+. NO NEED TO REVIEW text.
Using on-cluster layering to apply a custom layered image -- Updated text

QE review:

  • QE has approved this change.

@mburke5678 mburke5678 added this to the Continuous Release milestone Jul 15, 2025
@openshift-ci openshift-ci bot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Jul 15, 2025
@ocpdocs-previewbot
Copy link

ocpdocs-previewbot commented Jul 15, 2025

🤖 Wed Jul 16 19:09:33 - Prow CI generated the docs preview:

https://96116--ocpdocs-pr.netlify.app/openshift-enterprise/latest/machine_configuration/mco-coreos-layering.html


The credentials provided by the registry push secret that you added to the `MachineOSBuild` object must grant the permission for deleting an image from the registry. If the delete permission is not provided, the image is not removed when you delete the `MachineOSBuild` object.

Note that the custom layered image is not deleted if the image is either currently in use on a node or is desired by the nodes, as indicated by the `machineconfiguration.openshift.io/currentConfig` or `machineconfiguration.openshift.io/desiredConfig` annotation on the node.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The annotations for the image here is machineconfiguration.openshift.io/currentImage and machineconfiguration.openshift.io/desiredImage.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@umohnani8 Is this also the case in 4.19+? I would need to update the annotation in those branches also.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mburke5678 yes, that is the case in 4.19 and later as well

@sergiordlr
Copy link

/gltm

Thank you very much for the docs! they look good to me

@@ -0,0 +1,78 @@
// Module included in the following assemblies:
Copy link
Contributor Author

@mburke5678 mburke5678 Jul 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PEER REVIEW This file I copied directly from main (and 4.19). No need for review here.

@@ -0,0 +1,13 @@
// Module included in the following assemblies:
Copy link
Contributor Author

@mburke5678 mburke5678 Jul 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PEER REVIEW This file I copied directly from main (and 4.19). No need for review here.

Comment on lines 54 to 58
You can manually rebuild your custom layered image by either modifying your `MachineOSConfig` object or applying an annotation to the `MachineOSConfig` object as discussed in the following section. For more information, see "Rebuilding an on-cluster custom layered image".

If you used a custom machine config pool to apply an on-cluster layered image to a node, you can remove the custom layered image from the node and revert to the base image. For more information, see "Reverting an on-cluster layered node".

You can modify an on-custom layered image as needed, to install additional packages, remove existing packages, change repositories, update secrets, or other similar changes, by editing the MachineOSConfig object. For more information, see "Modifying a custom layered image".
Copy link
Contributor Author

@mburke5678 mburke5678 Jul 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PEER REVIEW These three lines (54, 56, 58) I copied directly from main (and 4.19). No need for review here.

* If you scale up a machine set that uses a custom layered image, the nodes reboot two times. The first, when the node is initially created with the base image and a second time when the custom layered image is applied.
* Node disruption policies are not supported on nodes with a custom layered image. As a result the following configuration changes cause a node reboot:
** Modifying the configuration files in the `/var` or `/etc` directory
** Adding or modifying a systemd service
** Changing SSH keys
** Removing mirroring rules from `ICSP`, `ITMS`, and `IDMS` objects
** Changing the trusted CA, by updating the `user-ca-bundle` configmap in the `openshift-config` namespace
* The images used in creating custom layered images take up space in your push registry. Always be aware of the free space in your registry and prune the images as needed.
* The images used in creating custom layered images take up space in your push registry. Always be aware of the free space in your registry and prune the images as needed. You can automatically remove an on-cluster custom layered image from the repository by deleting the MachineOSBuild object that created the image. Note that the credentials provided by the registry push secret must also grant permission to delete an image from the registry. For more information, see "Removing an on-cluster custom layered image".
Copy link
Contributor Author

@mburke5678 mburke5678 Jul 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PEER REVIEW This line I copied directly from main (and 4.19+). No need for review here.

@@ -98,7 +97,7 @@ $oc create secret docker-registry global-pull-secret-copy \

* You are familiar with how to configure a Containerfile. Instructions on how to create a Containerfile are beyond the scope of this documentation.

* Optional: You have a separate machine config pool for the nodes where you want to apply the custom layered image.
* Optional: You have a separate machine config pool for the nodes where you want to apply the custom layered image. One benefit to having a custom machine config pool for the nodes it that you can easily revert to the base image, if needed. For more information, see "Reverting an on-cluster layered node".
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PEER REVIEW This line I copied directly from main (and 4.19+). No need for review here.

Comment on lines 110 to 140
apiVersion: machineconfiguration.openshift.io/v1 <1>
kind: MachineOSConfig
metadata:
name: layered <2>
spec:
machineConfigPool:
name: worker <3>
buildInputs:
containerFile: <4>
- containerfileArch: noarch
content: |-
FROM configs AS final
RUN rpm-ostree install tree && \
ostree container commit
imageBuilder: <5>
imageBuilderType: PodImageBuilder
baseImagePullSecret: <6>
name: global-pull-secret-copy
renderedImagePushspec: image-registry.openshift-image-registry.svc:5000/openshift/os-image:latest <7>
renderedImagePushSecret: <8>
name: builder-dockercfg-7lzwl
buildOutputs: <9>
currentImagePullSecret:
name: builder-dockercfg-mtcl23
name: layered <3>
containerFile: # <4>
- containerfileArch: NoArch <5>
content: |-
FROM configs AS final
RUN dnf install -y cowsay && \
dnf clean all && \
ostree container commit
imageBuilder: # <6>
imageBuilderType: Job
baseImagePullSecret: # <7>
name: global-pull-secret-copy
renderedImagePushSpec: image-registry.openshift-image-registry.svc:5000/openshift/os-image:latest # <8>
renderedImagePushSecret: # <9>
name: builder-dockercfg-mtcl23
----
<1> Specifies the `machineconfiguration.openshift.io/v1` API that is required for `MachineConfig` CRs.
<2> Specifies a name for the `MachineOSConfig` object. This name is used with other on-cluster layering resources. The examples in this documentation use the name `layered`.
<3> Specifies the name of the machine config pool associated with the nodes where you want to deploy the custom layered image. The examples in this documentation use the `worker` machine config pool.
<2> Specifies a name for the `MachineOSConfig` object. This name is used with other [image-mode-os-on-lower] resources. The examples in this documentation use the name `layered`.
<3> Specifies the name of the machine config pool associated with the nodes where you want to deploy the custom layered image. The examples in this documentation use the `layered` machine config pool.
<4> Specifies the Containerfile to configure the custom layered image.
<5> Specifies the name of the image builder to use. This must be `PodImageBuilder`.
<6> Specifies the name of the pull secret that the MCO needs in order to pull the base operating system image from the registry.
<7> Specifies the image registry to push the newly built custom layered image to. This can be any registry that your cluster has access to. This example uses the internal {product-title} registry.
<8> Specifies the name of the push secret that the MCO needs in order to push the newly built custom layered image to that registry.
<9> Specifies the secret required by the image registry that the nodes need in order to pull the newly built custom layered image. This should be a different secret than the one used to push the image to your repository.
// +
// https://github.com/openshift/openshift-docs/pull/87486/files has the v1 api versions
<5> Specifies the architecture this containerfile is to be built for: `ARM64`, `AMD64`, `PPC64LE`, `S390X`, or `NoArch`. The default is `NoArch`, which defines a Containerfile that can be applied to any architecture.
<6> Specifies the name of the image builder to use. This must be `Job`, which is a reference to the `job` object that is managing the image build.
<7> Optional: Specifies the name of the pull secret that the MCO needs to pull the base operating system image from the registry. By default, the global pull secret is used.
<8> Specifies the image registry to push the newly-built custom layered image to. This can be any registry that your cluster has access to in the `host[:port][/namespace]/name` or `svc_name.namespace.svc[:port]/repository/name:<tag>` format. This example uses the internal {product-title} registry. You can specify a mirror registry if you cluster is properly configured to use a mirror registry.
<9> Specifies the name of the push secret that the MCO needs to push the newly-built custom layered image to that registry.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PEER REVIEW This code block and callouts I copied from main (and 4.19+). No need for review here.

@mburke5678 mburke5678 force-pushed the mco-ocl-418-backport branch from 3618050 to b4ba987 Compare July 16, 2025 18:58
Copy link

openshift-ci bot commented Jul 16, 2025

@mburke5678: all tests passed!

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

@mburke5678 mburke5678 added the peer-review-needed Signifies that the peer review team needs to review this PR label Jul 16, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
branch/enterprise-4.18 peer-review-needed Signifies that the peer review team needs to review this PR size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants